The present invention deals with entities in service oriented systems. More specifically, the present invention deals with the generation of a projection of an entity, owned by an owning service, on a consumer (which may also be a service) in a service oriented system.
A service is a system that a consumer of the service interacts with through a set of coarse-grained messages. A service oriented application may be composed of one or more services. Each of these application services typically contains a set of entities. Entities, in general, encapsulate data and provide a rich programming model for creating, reading, updating and deleting the data owned by the service.
Services typically contain private data and public data. The private data is encapsulated in an internal entity so that, within the service, the programming model provides access to all of the data and associations contained in the internal entity, but external to the service, the internal entity is not exposed through the service interface. However, public data is encapsulated in a publicly available entity which is available to consumers of the service.
It is common for a consumer of a service to access data of an entity owned by the service. One prior way for enabling this had the consumer directly access the owning service's data store. However, direct access to the owning service's data store requires the consumer of the data to have knowledge of the technology and table structure used by the owning service to store data in its data store. Similarly, such direct access allows the consumer to potentially view and change private data within the service. This is problematic for a number of reasons, and is discouraged in applications that honor the publicly known tenets of service orientation. These are set out in an article by Don Box entitled Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo, MSDN Magazine, January 2004. Basically, allowing an external service or client to bind directly to the owning service's data (either by access to the service's private entities or by directly accessing the data store which the service stores its data in) is a technique that compromises data integrity, the autonomy, and the explicit boundaries of the service in a service oriented environment. Instead, all communication with a service should occur using standardized message exchange.
In addition, many developers wish to develop systems in which the services are autonomous. Synchronizing and replicating data locally to the consumers of the service is often done to achieve such autonomy, because a given service does not then require the owning service to be available to retrieve data and process requests. However, a consumer may only be interested in a subset of the properties of the entity in the owning service.
In the past, in order to access only part of an entity, the consumer was required to have table-level access to the data in the owning service (which violates the tenets of service orientation as mentioned above), or it had to request the entire entity through the owning service's interface. Of course, an entity may have a very large number of properties (often in the hundreds) and a consumer may only require access to a very small number (such as five) of the properties. The consumer will normally not wish to incur all the overhead for processing such a large data set, when it only needs a small subset of the data.
This becomes even more important if functionality is provided to synchronize associated data to a local data store. Synchronization is the process through which data is replicated to a local data store and maintained by applying changes made to the owning service's data store to the consumer's data store. For instance, a consumer may wish to periodically synchronize a subset of the data from the owning service's data store to its own local data store. The consumer's local data store may be remote from the owning service's data store and may even be on a laptop computer or other mobile device. If the consumer is required to synchronize unwanted properties of an entity, this can greatly increase the amount of time and processing overhead required to perform the synchronization process. Further, when bringing a consumer on line, the initial synchronization of data can become burdensome and consume undesirable amounts of time and processing overhead.
Services also typically expose a plurality of publicly available data contracts. The data contracts identify the publicly available entities and the properties contained within those entities and specify how the entities are associated or related. Upon being queried through an interface, the service will generally provide access to data in the publicly available data contracts to the requestor.